Skip to content

A (very) slight speed improvement for iterating over bytes #21705

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
gvanrossum merged 1 commit into from
Aug 3, 2020
Merged

A (very) slight speed improvement for iterating over bytes #21705

gvanrossum merged 1 commit into from
Aug 3, 2020

Conversation

@gvanrossum
Copy link
Member

@gvanrossum gvanrossum commented Aug 2, 2020 •
edited
Loading

My mentee @xvxvxvxvxv noticed that iterating over array.array is
slightly faster than iterating over bytes. Looking at the source I
observed that arrayiter_next() calls getitem(ao, it->index++) wheras
striter_next() uses the idiom (paraphrased)

item = PyLong_FromLong(seq->ob_sval[it->it_index]);
if (item != NULL)
    ++it->it_next;
return item;

I'm not 100% sure but I think that the second version has less
opportunity for the CPU to overlap the index++ operation with the
rest of the code (which in both cases involves a call). So here I am
optimistically incrementing the index -- if the PyLong_FromLong() call
fails, this will leave the iterator pointing at the next byte, but
honestly I doubt that anyone would seriously consider resuming use of
the iterator after that kind of failure (it would have to be a
MemoryError). And the author of arrayiter_next() made the same
consideration (or never ever gave it a thought :-).

With this, a loop like

for _ in b: pass

is now slightly faster than the same thing over an equivalent array,
rather than slightly slower (in both cases a few percent).

@gvanrossum
A (very) slight speed improvement for iterating over bytes
66850f6 
My mentee @xvxvxvxvxv noticed that iterating over array.array is
slightly faster than iterating over bytes.  Looking at the source I
observed that arrayiter_next() calls `getitem(ao, it->index++)` wheras
striter_next() uses the idiom (paraphrased)

    item = PyLong_FromLong(seq->ob_sval[it->it_index]);
    if (item != NULL)
        ++it->it_next;
    return item;

I'm not 100% sure but I think that the second version has fewer
opportunity for the CPU to overlap the `index++` operation with the
rest of the code (which in both cases involves a call).  So here I am
optimistically incrementing the index -- if the PyLong_FromLong() call
fails, this will leave the iterator pointing at the next byte, but
honestly I doubt that anyone would seriously consider resuming use of
the iterator after that kind of failure (it would have to be a
MemoryError).  And the author of arrayiter_next() made the same
consideration (or never ever gave it a thought :-).

With this, a loop like

    for _ in b: pass

is now slightly *faster* than the same thing over an equivalent array,
rather than slightly *slower* (in both cases a few percent).
corona10
corona10 approved these changes Aug 3, 2020
View reviewed changes
Copy link
Member

@corona10 corona10 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gvanrossum

I measured that 2-3% speed improvement on follow script.

Benchmark

./python.exe -m pyperf compare_to master.json pr-21705.json
Mean +- std dev: [master] 443 us +- 10 us -> [pr-21705] 432 us +- 10 us: 1.02x faster (-2%)

Script

import pyperf

runner = pyperf.Runner()
runner.timeit(name="bench bytes iter",
              stmt="""for _ in datas: pass""",
              setup = """datas = b'a'*9999 """
)

@gvanrossum
Copy link
Member Author

gvanrossum commented Aug 3, 2020

@corona10 Thanks! I'll take it, but I'll wait a bit until for else to pipe up. Maybe there's a reason that I've forgotten we need to be extra careful with not incrementing the index until we're sure we have a result.

I also have a question about pyperf -- I'm not sure how I get JSON output from the script you show.

@corona10
Copy link
Member

corona10 commented Aug 3, 2020

@gvanrossum
You can get the JSON file by executing the attached script with the option :)

./python.exe bench_iter.py -o pr-21705.json

For more detail: https://github.com/psf/pyperf

@gvanrossum
Copy link
Member Author

gvanrossum commented Aug 3, 2020

Thanks! That is truly magical -- apparently pyperf parsers the command line even when it is not the __main__ program. I didn't see anything about this in the pyperf docs.

@gvanrossum
Copy link
Member Author

gvanrossum commented Aug 3, 2020

(And I now see that the pyperf's README file has this up front -- but I didn't think to look there, I only looked on readthedocs. :-( )

@gvanrossum gvanrossum merged commit 488512b into master Aug 3, 2020
@gvanrossum gvanrossum deleted the faster-bytes-iter branch August 3, 2020 16:04
@bedevere-bot
Copy link

bedevere-bot commented Aug 3, 2020

@gvanrossum: Please replace # with GH- in the commit message next time. Thanks!

shihai1991 pushed a commit to shihai1991/cpython that referenced this pull request Aug 4, 2020
@gvanrossum @shihai1991
A (very) slight speed improvement for iterating over bytes (python#21705
2edc37a 
)

My mentee @xvxvxvxvxv noticed that iterating over array.array is
slightly faster than iterating over bytes.  Looking at the source I
observed that arrayiter_next() calls `getitem(ao, it->index++)` wheras
striter_next() uses the idiom (paraphrased)

    item = PyLong_FromLong(seq->ob_sval[it->it_index]);
    if (item != NULL)
        ++it->it_next;
    return item;

I'm not 100% sure but I think that the second version has fewer
opportunity for the CPU to overlap the `index++` operation with the
rest of the code (which in both cases involves a call).  So here I am
optimistically incrementing the index -- if the PyLong_FromLong() call
fails, this will leave the iterator pointing at the next byte, but
honestly I doubt that anyone would seriously consider resuming use of
the iterator after that kind of failure (it would have to be a
MemoryError).  And the author of arrayiter_next() made the same
consideration (or never ever gave it a thought :-).

With this, a loop like

    for _ in b: pass

is now slightly *faster* than the same thing over an equivalent array,
rather than slightly *slower* (in both cases a few percent).
shihai1991 pushed a commit to shihai1991/cpython that referenced this pull request Aug 20, 2020
@gvanrossum @shihai1991
A (very) slight speed improvement for iterating over bytes (python#21705
54ea8c6 
)

My mentee @xvxvxvxvxv noticed that iterating over array.array is
slightly faster than iterating over bytes.  Looking at the source I
observed that arrayiter_next() calls `getitem(ao, it->index++)` wheras
striter_next() uses the idiom (paraphrased)

    item = PyLong_FromLong(seq->ob_sval[it->it_index]);
    if (item != NULL)
        ++it->it_next;
    return item;

I'm not 100% sure but I think that the second version has fewer
opportunity for the CPU to overlap the `index++` operation with the
rest of the code (which in both cases involves a call).  So here I am
optimistically incrementing the index -- if the PyLong_FromLong() call
fails, this will leave the iterator pointing at the next byte, but
honestly I doubt that anyone would seriously consider resuming use of
the iterator after that kind of failure (it would have to be a
MemoryError).  And the author of arrayiter_next() made the same
consideration (or never ever gave it a thought :-).

With this, a loop like

    for _ in b: pass

is now slightly *faster* than the same thing over an equivalent array,
rather than slightly *slower* (in both cases a few percent).
xzy3 pushed a commit to xzy3/cpython that referenced this pull request Oct 18, 2020
@gvanrossum
A (very) slight speed improvement for iterating over bytes (python#21705
db89dd8 
)

My mentee @xvxvxvxvxv noticed that iterating over array.array is
slightly faster than iterating over bytes.  Looking at the source I
observed that arrayiter_next() calls `getitem(ao, it->index++)` wheras
striter_next() uses the idiom (paraphrased)

    item = PyLong_FromLong(seq->ob_sval[it->it_index]);
    if (item != NULL)
        ++it->it_next;
    return item;

I'm not 100% sure but I think that the second version has fewer
opportunity for the CPU to overlap the `index++` operation with the
rest of the code (which in both cases involves a call).  So here I am
optimistically incrementing the index -- if the PyLong_FromLong() call
fails, this will leave the iterator pointing at the next byte, but
honestly I doubt that anyone would seriously consider resuming use of
the iterator after that kind of failure (it would have to be a
MemoryError).  And the author of arrayiter_next() made the same
consideration (or never ever gave it a thought :-).

With this, a loop like

    for _ in b: pass

is now slightly *faster* than the same thing over an equivalent array,
rather than slightly *slower* (in both cases a few percent).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@corona10 corona10 corona10 approved these changes

Assignees

No one assigned

Labels

skip issue skip news

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@gvanrossum @corona10 @bedevere-bot @the-knights-who-say-ni